REMARKS 



Claims 1-38 are currently pending in the application. The Examiner rejected claims 1-38 
under 35 U.S.C. 102(e) as being anticipated by Zhu (U.S. Patent No. 6,201,834). The 
independent claims have been amended to recite "annotating a bitstream header" or "annotating 
a video stream header" with network packet information specifying network packet boundaries. 
The bitstream header or video stream header is used to divide a modified bitstream into network 
packets for real-time streaming. 

The amendment language is supported on page 13 line 26 of the specification. More 
specifically, "The reformatting of the elementary video stream 210 to the modified video stream 
215 includes the addition of network packet information 314 in the modified video stream 215. 
In one embodiment, the network packet information 314 is appended onto the sequence header 
302 in the modified video stream 206. In another embodiment, the network packet information 
314 is inserted within the GOP header 304. . . In one embodiment, the inserted information 
includes network packet information, which provides the starting byte indexes of MPEG packets 
corresponding to the GOP header 304. In a specific embodiment, the network packet 
information inside each GOP header 304 contains the starting byte indexes and lengths of each 
RTP data packet from the GOP." 

It is believed that Zhu does not teach or suggest providing network packet information 
specifying network packet boundaries in a bitstream header. In one embodiment, the bitstream 
header includes network packet byte indices to allow a segmenter to quickly divide a bitstream 
payload into packets without having to scan and copy the bitstream payload as was required in 
conventional implementations. For example, a segmenter can read a bitstream header and know 
the exact locations of each packet in the bitstream payload. 

Zhu does not teach or suggest any mechanisms for performing this task. Zhu describes a 
system for recovering video bitstream packets lost during transmission. The video bitstream 
includes three parts. The first part is the standard compressed bitstream (column 3, lines 19-21), 
the second part is the bistream information stream, and the third part is the bitstream information 
trailer (column 3, lines 25-41). 
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The bitstream information stream includes a PACKET LOST flag to indicate when a 
packet is lost (column 3, lines 26-28). The bitstream information stream also has data that 
identifies which of the video frame data are lost and indicate parameters for decompressing the 
compressed bitstream. (Abstract) Replacement compressed bitstream data is placed in the 
compressed bitstream in place of video frame data in the lost packet so that uncompressed video 
image data can be generated based on the data in the bitstream information stream. (Abstract) 

The Examiner argued that Zhu discloses that the beginning of the bitstream information 
stream is associated with a double word boundary and that the first structure of the first packet is 
co-located at the beginning of the bitstream. However, having a first packet coincide with the 
beginning of the bitstream information stream is not "annotating a bitstream header to include 
network packet information specifying network packet boundaries." The Examiner further 
argues that once the beginning of the bitstream information stream is found, the bit offset field 
indicates the packet boundary. However, the bit offset field is contained in the bitstream 
information stream itself. 

Zhu is believed to merely add error correction capabilities to a system that uses a 
conventional mechanism for splitting a bitstream. Zhu's conventional packet splitting 
mechanism does not "rapidly divide the bitstream into network packets for real-time streaming." 
The techniques of the present invention recognize the drawbacks of splitting a bitstream using a 
conventional mechanism. From the Background of the present application (page 4, line 19 - 
page 5, line 5), "there are several problems commonly encountered when repacketizing MPEG 
data into RTP packets. First, the server 103 must parse the entire MPEG bitstream, bit by bit, in 
order to determine how it will carve the MPEG system stream. More specifically, it must parse 
the entire MPEG bitstream to apply the protocol rules to locate appropriate start and end points 
for each RTP packet. In addition, the server must gather information to create the RTP packet 
headers. This parsing and information gathering imposes substantial processing load on the 
server CPU and may limit the ability of the server 103 to deliver real-time multimedia." 

"The second problem arises because two copy operations are required to parse the 
bitstream. The first copy operation transfers the MPEG data from the file 102 into the buffer 108 
where it is parsed. The second copy operation moves the data from the buffer 108 into the 
network packets. These two copy operations require significant CPU processing load, which 
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again may limit the ability of the server 103 to deliver real-time multimedia." 

Consequently, the independent claims of the present application recite annotating a 
bitstream header with information specifying network packet boundaries allowing an apparatus 
to "rapidly divide the bitstream into network packets using the bitstream header for real-time 
streaming." In one example, the bitstream header includes a plurality of network packet indices 
According to various embodiments, by providing network packet indices in a single location, a 
scan and copy of the bitstream payload as required by Zhu would not be needed. 

In view of the foregoing. Applicants believe all independent and dependent claims now 
pending in this application are in condition for allowance. If the Examiner believes a telephone 
conference would expedite prosecution of this application, please telephone the undersigned at 
(510) 843-6200. 

Respectfully submitted, 




P.O. Box 778 

Berkeley, CA 94704-0778 
(510) 843-6200 
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